[レポート] オンラインイベント Prometheus Meetup Tokyo #4 #prometheustokyo

クラウド世代の監視ツール Prometheus のミートアップ、第4回目はオンライン開催でした。当ミートアップは毎回登壇者が熱く、運営が丁寧なので、好んで参加していましたが、今回も非常に興味深い話を聞くことができました。

セキュリティ製品特集

#Prometheus

#イベントレポート

#監視サービス

渡辺聖剛

2020.05.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

5/28、オンラインイベント Prometheus Meetup Tokyo #4 が開催されました。300人を超す参加申込みのあった本イベントをレポートします。
ぼく自身Prometheusは実運用で使えていないので、このような場で実践の現場の声が拾えるのはとても興味深く助かってます。今回もこれまでのように、Prometheusをヘビーに使われている方々からの非常に実践的なお話を伺うことが出来ました。

なお、本イベントは YouTube Live にてリアルタイム配信され、質疑は sli.do にて受け付けられました。

既に配信内容ならびに資料も公開されているので、是非こちらもご覧下さい。

以下、Kubernetesのことをk8sと略記していますがご了承下さい。

Unit Testing for Prometheus Rules (40min)

資料 : Unit Testing for Prometheus Rules - Speaker Deck

スピーカー : 久住貴史氏, ゼットラボ株式会社

Prometheus の運用において、アラートルールなど PromQL のテストやレビューが難しいという問題があります。また、PromQL を試してみたいと思っても、前提となるメトリクスの準備が難しく、気軽に試せないという課題もあります。本発表では promtool 使ったユニットテストで、これらの問題を解決する方法を紹介します。

Prometheusルールの運用課題
- ルールを簡単に検証できない
- レビューが難しい
- 学習しづらい
- 原因 -> メトリクスのテストデータを準備することが難しいため
もうひとつの課題
- ルールの構文が間違っているとPrometheusが起動に失敗する
promtool
- Prometheusに付属
  - prometheus/cmd/promtool at master · prometheus/prometheus
- Dockerやhomebrewパッケージにも含まれる
- promtool test rules <test-rule-file>
- テスト用のメトリクスデータが簡単に準備できる
- 設定・ルールファイルの構文チェックも便利
実演(Demo)
値の省略記法
- y+ax みたいに記述できる
- value 100+10x5 -> 100 110 120 130 140 150
  - 110〜160ではないので注意
- 活用
  - アラートのforが長いとき
  - range vectorの範囲が広いとき
  - カウンタ値のテスト
PromQLの試し方
- Recording Ruleもこの方法

promtool Tips
- まずはpromtool check rulesでルールの構文チェック
  - これだけで構文エラーで落ちる問題を防げる
- promtoolをDockerで実行する
  - prom/prometheusイメージに含まれる
  - entrypointを変える必要がある
  - nobodyユーザで実行するのに -u root オプションが必要な場合も
- ユニットテスト時のタイムスタンプ
  - UNIXエポックから始まる
  - 時刻関連の関数を含むクエリでは意識する必要がある
    - タイムゾーンがUTCであることも注意
ユニットテストで学ぶPrometheus
- 浮動小数点の精度
  - メトリクスの値はGoのfloat64
  - 0.1 + 0.2 = 0.30000...0004
  - 演算結果を == で比較する場合は注意
  - くわしくは : Storing 16 Bytes at Scale | PromCon 2017
- StalenessとStaleness Maker
  - 値がなくても、直近5分はメトリクスを取得できる（最後の値が繰り返される）
  - むしろ、これを考慮せずに「値がないはず」と思ってテストすると意図通りに動かない
  - Scrapeの失敗や、Time Seriesが存在しなくなった場合にStaleness Maker（stale）という特別な値が入る
  - 判定が遅れる問題や重複カウントされる問題が回避される
  - くわしくは : Staleness in Prometheus 2.0 | PromCon 2017
まとめ
- promtoolを使えばルールの検証が簡単
  - メトリクスデータの準備が簡単
  - ルールの作成やレビューの効率が上がる
- ルールの構文チェックだけでも有用
- PromQLを学ぶにもpromtoolは最適
Q&A
- テストデータをPromにインポートすることはできるか？
  - promtoolではできない
- スクレイプしたタイミングで値が取れなかった場合のテストは？
  - Staleness Makerを使う

監視ツールのアラートは試験が難しい（面倒）、というのは何を使っていても共通だと思っていたんですが、テストデータをオンデマンドで用意できるのは素敵ですね。
Q&Aにもありましたが、実際にその値をストアできるとまたテスト範囲が広がって良さそうに思いましたが（当然また別の問題もでてくると思いますが…）現状は出来ないとのことで、promtoolが目指すところではないということなのかなと思いました。

Survey and Short Dive Prometheus Operator (30min)

資料 : Survey and Short Dive Prometheus Operator - Speaker Deck

スピーカー : Shuya Motouchi氏, GMOインターネット

インフラストラクチャソフトウェアは、パラダイムシフトの真っ只中にあります。今回はクラウドネイティブな監視の監視及び課題の整理をした後にPromerrheus Operator についてその概要についてとkustomizeでの商材サイトの管理及びArgoCDでの監視自動化についての事例を一つ紹介したいと思います。

クラウドネイティブな監視

仮想化からクラウドネイティブへ
クラウドネイティブとは
- 定義 : toc/DEFINITION.md at master · cncf/toc
- 疎結合なシステム
- 回復性
- 管理力
- 可観測性
- 堅牢な自動化により、頻繁か付きたい通りに最小限の労力で大きな変更が可能
- -> OpenかつScalableなシステムを実現
  - 運用されるソレは動的
動的なシステムを監視するのはつらい
- 何もしないと壊れる
- どう手を尽くしても「よく分からない状態」になる

サービス検出（Service Discovery）
- 入門Prometheus 8章

Prometheus Operator

k8s上で動作するPrometheus
Custom resourceとCustom controllerによってPrometheusの運用や設定を自律化する
Custom Resource Definitions
- Prometheus
- Alertmanager
- PrometheusRule
- ServiceMonitor
- PodMonitor

ArgoCDとkustomizeで実現する監視設定自動化

ArgoCD
- GitOpsを提供
実例：商材サイトと呼んでいるもの
- 課題
  - Webサイトごとの環境分離ができずいライブラリ管理が…
  - 様々な背景から本番と検証とその他多くの環境で差異
  - 伝統芸化
  - 似たような環境が100サイト
- 達成したかったこと
  - 環境の分離
  - 環境の整理
  - 運用のコード化・自動化
- kustomizeを使った（構成管理システム）
Kustomize
- k8sのYAMLをパッケージングする
- 出力が単一のYAMLになる
- Helmとの違い
  - Helmは学習コストが高い、kustomizeはYAMLの入出力だけやればなんとかなる
Prometheus Operatorで困っていること
- Blackbox Exporter
- Scrape Configsの更新を上手くやっていく良い方法を探している
  - Prometheusエンドポイントにreloadがある（〜/-/reload）
  - Prometheus Operatorは5分ごとに自動的にreloadしているので放置してもよい
Q&A
- upstreamに追随していくための良い方法
  - かめねこさんのTwitterを見て気付く
  - ReleaseNoteを読む、リリースをメールで飛ばすようにしている
  - バージョンアップしていくことについては、promtoolを使ったりして検証していく
- Prometheusを1つしか建てないときのOperatorの利点
  - Prometheusはある程度冗長化が必要なので（その際に楽になる
  - Operatorを覚えるのも大変なので、さいしょは普通に建てた方がいいかもしれない

Prometheusとk8sの相性が良いことがまたひとつ証明されてしまいました。
個人的に、Prometheusは大きくひとつ建てて集中管理するより、環境ごとに多く建てる（堅牢性はそこまで求めない）ような使い方が初期の思想にありそうに思います。そこをカバーするために Thanos のようなHAプロダクトもあれば、構築そのものを軽くするOperatorのような方向性もあるということで、多様性を感じられたセッションでした。

(LT) kube-prometheusを気軽にKustomize

資料 : kube-prometheusを気軽にKustomize - Speaker Deck

スピーカー : 大塚元央氏, ゼットラボ株式会社

自宅で手軽にクラスタ環境を手に入れられる

API ServerはMetalLBでself-hosted バランシング
自宅クラスタを労なく監視したい
kube-prometheusとは
- Prometheusでk8sおよびk8s上のアプリケーションを監視するためのk8sマニフェストを生成するライブラリ
- アラートルールやダッシュボードが展開される
適当に使う際の問題点
- jsonnetライブラリ
- jsonnetを（このためだけに）覚えたくない
- Quickstartとしてコンパイル済みのマニフェストが置いてある
  - これを使えないか？
Quickstartのマニフェストだと足りない
- kube-rbac-proxyがarm64未対応
- Alertmanagerの通知先
- Ingressがない
  - Grafanaにアクセス出来ない
- Prometheus、AlertmanagerのexternalUrlがおかしい
- 永続化されていない（Grafana）
- 自作のcollectorを使いたい
Kustomizeでカスタマイズすればいい
- Grafanaダッシュボードの追加も可能
まとめ：jsonnet知らなくても意外とkustomizeできるのでオススメ！

途中でハプニングがあり数分中断されてしまいましたが（リモートあるある）、Prometheusを使いだすハードルを下げる非常に有益なお話だったと思います。
そういえば以前、Prometheusの運用場所として「タンスの上」というアンケート結果を見たことがあるのですが、自宅サーバ・クラスタの監視にPrometheusというのはもはや業界のスタンダードなのでしょうか。。